サイボウズ ガルーンをAWSに構築してみた
まいど、大阪の市田です。
今回は、サイボウズ ガルーン(以下、ガルーンと表記)をAWS環境に構築してみたので、そのご紹介になります。
構成
今回は下記ドキュメントにある「サーバ分離構成」を構築しました。
実際の構成図は以下です。
AWSでデータベースといえばRDSがよく利用されますが、ガルーンの場合、DBに対してNFSマウントする必要があるので、今回は全てEC2で作成します。
インスタンスのOS
ガルーンがサポートしているLinuxはRed Hat Enterprise Linux 5〜7なので、今回は2017年8月時点で最新の下記AMIを利用しました。
- Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type - ami-30ef0556
EBSサイズやインスタンスタイプは利用可能な最小のものにしています。
Security Group
セキュリティグループは下記の通りです。
Appサーバ用グループ
| ポート | プロトコル | ソース | 備考 |
|---|---|---|---|
| 80 | TCP | ELBのSecurity Group | ELBからのアクセス用途です |
| 22 | TCP | 踏み台サーバのSecurity Group | 踏み台サーバからのアクセス用途です |
DBサーバ用グループ
| ポート | プロトコル | ソース | 備考 |
|---|---|---|---|
| 3770 | TCP | AppサーバのSecurity Group | AppサーバからのDB(バンドル版MySQL)アクセス用途です |
| 2049 | TCP | AppサーバのSecurity Group | AppサーバからのNFSv4アクセス用途です |
| 22 | TCP | 踏み台サーバのSecurity Group | 踏み台サーバからのアクセス用途です |
ELB用グループ
ACMでHTTPSによるアクセスを行いたいので、443ポートのみ許可しています。
| ポート | プロトコル | ソース | 備考 |
|---|---|---|---|
| 443 | TCP | 拠点IP | ガルーン利用拠点からのアクセス用途です |
踏み台サーバ用グループ
| ポート | プロトコル | ソース | 備考 |
|---|---|---|---|
| 22 | TCP | 拠点IP | 保守拠点からのアクセス用途です |
やってみた
上記の通り、VPCとインスタンスを作成して下さい。特に難しい部分は無いかと思いますので、それぞれについては割愛させて頂きます。
ガルーンのインストール
それではドキュメントに従って作業を行っています。
ドキュメントによると、途中までは全てのサーバで同じ作業を実施することになっているので、この節での作業は3台全てのサーバで実施して下さい。
まずはApacheをインストールして、KeepAlive設定を無効にします。
# yum -y install httpd # echo "KeepAlive Off" >> /etc/httpd/conf/httpd.conf # systemctl start httpd
Appサーバの場合は自動起動を有効にしておきましょう。
# systemctl enable httpd.service
次にSELinuxを無効化します。正しくポリシーを設定することでSELinuxが有効でも問題ないかと思いますが、検証の時間が取れなかった為、ドキュメントに記載の通りに進めます。
# sed -i -e 's/enforcing/disabled/g' /etc/selinux/config
設定を反映させる為、再起動します。
# reboot
再起動が完了したらガルーンに必要なパッケージ等をインストールします。
# yum -y install libaio libjpeg-turbo libpng perl perl-Data-Dumper wget unzip
これで準備ができたので、ガルーンをインストールします。
今回は下記の試用版のガルーンを利用します。下記のページから「サイボウズ ガルーン 4.2」のLinux(64bit)版をダウンロードします。
今回はサーバから直接インストーラをダウンロードして実行します。インストーラのURLはタイミングによって変わる可能性があるので、上記サイトで確認してから実行して下さい。
# wget http://download.cybozu.co.jp/cbgrn/grn-4.2.0-linux-x64.bin # sh /tmp/grn-4.2.0-linux-x64.bin
最初に試用許諾契約が表示されるので、スペースキーまたはEnterキーで一番下まで目を通します。
試用許諾契約に同意の場合は「yes」を入力して下さい。
次にインストール識別子を指定です。デフォルトのままとします。必要に応じて指定して下さい。
使用するMySQLの選択です。バンドル版のものが推奨とのことなので「1」を選択します。
ガルーンのプログラムとデータのインストールディレクトリーの指定です。ここもデフォルトのままとします。必要に応じて指定して下さい。
次に各種パスワードの設定です。ここでは以下のパスワードを設定します。これらのパスワードは3台のサーバで全て同一にして下さい。
- MySQLの管理ユーザのパスワード
- MySQLの接続ユーザのパスワード
- ガルーンの管理者(Administrator)のパスワード
AppサーバーのCGIディレクトリーの指定です。デフォルトのままとします。必要に応じて指定して下さい。
Appサーバーのドキュメントルートディレクトリーの指定です。これもデフォルトのままとします。必要に応じて指定して下さい。
Webサーバーの実行ユーザー名の指定です。正しければそのままEnterキーを押します。間違っていれば正しいものを指定して下さい。
最後にサマリーが表示されます。問題無ければ「yes」を入力して、インストールを実行して下さい。
インストールが完了すると、完了の表示やガルーンのログインURL等が表示されます。
このログインURLはインストーラで一意に表示されているようなので、適宜読み替えて下さい。
インスタンスの搭載メモリー量が8GB以上の場合は、mysqldの設定を変更する必要があるようですが、今回は検証用としてt2.microを利用しているので、設定はそのままとします。ご利用の環境に応じて変更して下さい。
尚、変更内容はガルーンのインストールドキュメントに記載されています。
(P.35「2.4.2節 MySQL の設定を変更する」参照)
以上の作業を全てのサーバで実行します。
サーバー分離構成に変更する
ここからは、ドキュメントのP.50「5章 サーバー分離構成で運用する」を参考に作業を進めていきます。
まず、全てのサーバーで、Webサーバー（httpd）を停止します。
# systemctl stop httpd.service
次に全てのサーバーでガルーンのサービスを停止します。停止するサービスはスケジューリングサービスとバンドル版MySQLの2つです。
# /etc/init.d/cyss_cbgrn stop # /etc/init.d/cyde_5_0 stop
プロセスが全て停止できたら、各Appサーバのデータベース接続先の設定を変更します。
/var/www/cgi-bin/cbgrn/lwc.iniの設定を次のように編集します。
prop:_host = "val:127.0.0.1:3770" ↓ prop:_host = "val:＜DBサーバのプライベートIP＞:3770"
各Appサーバーのセッションデータの保存方法を確認します。/var/www/cgi-bin/cbgrn/php.iniに記載の[Session]セクションでsession.save_handler = filesとなっていることを確認します。
もし他の値が設定されている場合は「files」に変更して下さい。
[Session] session.save_handler = files
次に全てのサーバのデータの保存領域の設定を確認します。/var/www/cgi-bin/cbgrn/common.iniに記載の[Session]セクションでsave_pathと、[Files]セクションのdirの設定が下記のようになっていることを確認して下さい。
(中略) [Session] cookie_lifetime = "0" cookie_path = "/" file_lifetime = "1" save_path = "/var/www/cgi-bin/cbgrn/sessiondata/" handler = "file" (中略) [Files] dir = "/usr/local/cybozu/mysql-5.0/files/cbgrn"
上記の設定を踏まえて、DBサーバ(db-01)でNFSの設定を行います。DBサーバの/etc/exportsを下記のように記載します。
AutoScaling環境など、AppサーバのIPアドレスが変わることもあり得るのでサブネット単位で指定しています。
/var/www/cgi-bin/cbgrn/sessiondata 10.0.3.0/24(rw) 10.0.4.0/24(rw) /usr/local/cybozu/mysql-5.0/files 10.0.3.0/24(rw) 10.0.4.0/24(rw)
次にDBサーバにNFSサーバをインストールして起動します。自動起動設定も有効化しておきましょう。
# yum -y install nfs-utils # systemctl enable nfs-server # systemctl start nfs-server
確認します。
# exportfs -v
/var/www/cgi-bin/cbgrn/sessiondata
10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/var/www/cgi-bin/cbgrn/sessiondata
10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/usr/local/cybozu/mysql-5.0/files
10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/usr/local/cybozu/mysql-5.0/files
10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
次に、各Appサーバのデータ保存領域の書き込み権限を変更します。
# chmod -R 000 /var/www/cgi-bin/cbgrn/sessiondata # chmod -R 000 /usr/local/cybozu/mysql-5.0/files
両方のAppサーバからDBサーバをNFSマウントします。
# yum -y install nfs-utils
「rpcbind」と「nfslock」を起動します。
# systemctl start rpcbind.service # systemctl start nfs-lock.service
rpcbindの状態を確認します。
# systemctl status rpcbind.service
● rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
Active: active (running) since Thu 2017-08-31 07:18:59 UTC; 7min ago
Main PID: 13491 (rpcbind)
CGroup: /system.slice/rpcbind.service
└─13491 /sbin/rpcbind -w
Aug 31 07:18:59 ip-10-0-3-138.ap-northeast-1.compute.internal systemd[1]: Starting RPC bind service...
Aug 31 07:18:59 ip-10-0-3-138.ap-northeast-1.compute.internal systemd[1]: Started RPC bind service.
nfs-lockの状態を確認します。
# systemctl status nfs-lock.service
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; static; vendor preset: disabled)
Active: active (running) since Thu 2017-08-31 07:22:04 UTC; 4min 26s ago
Main PID: 13512 (rpc.statd)
CGroup: /system.slice/rpc-statd.service
└─13512 /usr/sbin/rpc.statd
Aug 31 07:22:04 ip-10-0-3-138.ap-northeast-1.compute.internal systemd[1]: Starting NFS status monitor for NFSv.....
Aug 31 07:22:04 ip-10-0-3-138.ap-northeast-1.compute.internal rpc.statd[13512]: Version 1.3.0 starting
Aug 31 07:22:04 ip-10-0-3-138.ap-northeast-1.compute.internal rpc.statd[13512]: Flags: TI-RPC
Aug 31 07:22:04 ip-10-0-3-138.ap-northeast-1.compute.internal rpc.statd[13512]: Initializing NSM state
Aug 31 07:22:04 ip-10-0-3-138.ap-northeast-1.compute.internal systemd[1]: Started NFS status monitor for NFSv2.....
自動起動を有効化しておきましょう。
# systemctl enable rpcbind # systemctl enable nfs-lock
各Appサーバで、DBサーバのデータ保存領域をマウントします。
まず、セッションデータ保存領域をマウントします。
# mount -o intr,noac ＜DBサーバのプライベートIP＞:/var/www/cgi-bin/cbgrn/sessiondata /var/www/cgi-bin/cbgrn/sessiondata
次に添付ファイル保存領域をマウントします。
# mount -o intr ＜DBサーバのプライベートIP＞:/usr/local/cybozu/mysql-5.0/files /usr/local/cybozu/mysql-5.0/files
マウント出来ているか確認します。
(下記は私の環境での表示なので、ご利用環境によってIPアドレスなどが異なる場合があります。)
# mount |grep "10.0.5" 10.0.5.145:/var/www/cgi-bin/cbgrn/sessiondata on /var/www/cgi-bin/cbgrn/sessiondata type nfs4 (rw,relatime,sync,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.3.138,local_lock=none,addr=10.0.5.145) 10.0.5.145:/usr/local/cybozu/mysql-5.0/files on /usr/local/cybozu/mysql-5.0/files type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.3.138,local_lock=none,addr=10.0.5.145)
appサーバが再起動してもマウントできるように/etc/fstabに下記を追記しておきましょう。
＜DBサーバのプライベートIP＞:/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata /var/www/cgi-bin/cbgrn/sessiondata nfs intr,noac 0 0 ＜DBサーバのプライベートIP＞:/mnt/DIR1/cybozu/mysql-5.0/files /usr/local/cybozu/mysql -5.0/files nfs intr 0 0
Appサーバではガルーンを利用しないので、関連サービスの自動起動を無効化しておきます。
# systemctl disable cyde_5_0 # systemctl disable cyss_cbgrn
ガルーンの起動
DBサーバでガルーンのサービスを起動します。
# /etc/init.d/cyde_5_0 start # /etc/init.d/cyss_cbgrn start
各Appサーバでhttpdを再開します。
# systemctl start httpd.service
確認
これで構築が完了しましたので、ELBに関連付けているURLでアクセスしてみます。今回はテストドメインに対して、ACMでHTTPSアクセスにしています。
https://＜テストドメイン＞/cgi-bin/cbgrn/grn.cgi
適当にクリックしてガルーンを操作して下さい。
両方のAppサーバでガルーンに対するアクセスログが出ていれば、ELB経由でアクセスが振り分けられていることが分かります。
[ec2-user@ip-10-0-3-138 ~]$ sudo tailf /var/log/httpd/access_log |grep -v "ELB-HealthChecker" 10.0.2.156 - - [31/Aug/2017:08:05:16 +0000] "GET /cgi-bin/cbgrn/grn.cgi/todo/index? HTTP/1.1" 200 32635 "https://garoon.awstest.info/cgi-bin/cbgrn/grn.cgi/memo/index?" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" (以下略)
[ec2-user@ip-10-0-4-150 ~]$ sudo tailf /var/log/httpd/access_log |grep -v "ELB-HealthChecker" 10.0.2.156 - - [31/Aug/2017:08:06:04 +0000] "GET /cbgrn/grn/image/cybozu/linklist20.gif?20151103.text HTTP/1.1" 200 1055 "https://garoon.awstest.info/cgi-bin/cbgrn/grn.cgi/link/index?" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" (以下略)
DBサーバの冗長化対応
今回の構成ではDBサーバが単一構成なので、ここがSPOFになってしまいます。その為DBサーバの冗長化を検討したいところですが、いくつか方法がありそうです。
- HAクラスタソフトによるフェイルオーバー
- CloudWatchやEC2 Systems Manager等を活用したフェイルオーバー
- 冗長化ではないけどEC2 Auto RecoveryでDBサーバを自動復旧
パッと上記のような方法が思いつきますが、これについては次回試してみたいと思います。
最後に
今回はドキュメント通りの構成にしていますが、DBサーバを冗長化してAppサーバにはAutoScalingを導入すれば、さらに可用性が高くなるかと思います。
先程記載しましたように、冗長化対応については今後紹介していきたいと思います。
以上です。
![[小ネタ] Windows AMIの更新通知の購読をAWS CLIから行う](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-daa54df39308ec469607d6a913b81811/3c36486880ec490db06f2c3f36080c43/amazon-sns)
